In communications networks, when a plurality of packets is sent from an origin to a destination for a shared purpose, the packets are collectively called a session. Network carriers may be interested in statistical data related to sessions traversing their networks. This data, hereinafter referred to as session information, can be collected by network elements that route and/or process packets belonging to network sessions. Examples of network elements that may perform such routing or processing include media gateways (MGs) and session border controllers (SBCs). Session information may be contained in portions of packets belonging to each session and therefore can be collected by extracting these portions from network packets associated with a communication session. For example, in communications sessions, such as voice over Internet protocol (VoIP)-to-VoIP sessions, which utilize real time transport control protocol (RTCP) packets to control the session, at least five types of session information are contained in each packet.
First, the session information data field, referred to as the sender's packet count, stores the total number of real time transport protocol (RTP) packets transmitted by the sender since the session was initiated. This count is reset at the beginning of each session.
Second, the sender's octet count data field stores the total number of RTP payload octets transmitted by the sender since the beginning of the session. The sender's octet count includes 32-bits and may be used to estimate the average payload data rate.
Third, the fraction lost data field stores the number of packets lost divided by the number of RTP packets expected. This number is expressed as a fixed point number with the binary point at the left edge of the field.
Fourth, the cumulative number of packets lost data field stores the total number of RTP packets belonging to a single source that were lost since the session began. The number of lost packets is equal to the expected number of packets minus the number of packets received, where the received packets include duplicate and late packets.
Fifth, the interarrival jitter data field stores a mathematical estimate of the variance in the arrival times of RTP packets. This jitter is measured as the difference between the spacing of a sender's RTP packets and the spacing of the packets when the destination receives them. This can also be viewed as the difference between the transit times of individual packets in an RTP packet stream.
Typically, session information generated by a communication session is sent to a centralized central processing unit (CPU) or one or more digital signal processors (DSPs) of a network node, such as a media gateway, for processing. In addition to processing session information, these CPUs and DSPs perform tasks such as call set-up and tear-down and codec conversion. The primary functions just described are resource intensive, and thus limit the processing resources these CPUs and DSPs can dedicate to also processing session data.
One type of network element that may receive RTCP information is a media gateway. A media gateway (MG) is a mediation device that translates communications traffic between different networks, such as public switched telephone network (PSTN) and Internet protocol (IP) networks. Media gateways receive incoming packets and process and/or route the packets. For example, media gateways can receive packets belonging to a VoIP session from an IP network, convert the voice information in the packets to a different codec, and forward the voice information to a PSTN network. Media gateways can also receive network packets from an IP network and route the packets to another IP network if codec conversion is needed. In addition to these core functions, one or more resources in a MG, such as the DSPs, can collect and analyze session information relating to the network traffic it processes.
Another type of network elements that may receive RTCP information is a session border controller (SBC). An SBC is a device that manages VoIP calls at the border of IP networks by managing the control and media signaling associated with setting up, conducting, and tearing down VoIP calls. Additionally, SBCs may enforce firewall permissions or quality of service (QoS) protocols. SBCs may also collect and analyze session information for the network traffic it processes. Both MGs and SBCs currently collect and analyze communications session information remotely using a central CPU or one or more DSPs.
Current methods and systems for collecting and analyzing communication session information that forward packets to a remote processor have several disadvantages. First, the time required to forward packets via a switching fabric or a communication bus to remote processors limits the number of packets per second a MG or SBC can process, and thus limits their scalability. Second, in the event of a link failure between the network interface module, where packets are received, and the remote processor where the packets' session information is collected and analyzed, no session information can be collected until the link returns to availability. Third, because remote processors in current systems also perform tasks vital to the operation of the network element, such as call set-up and tear-down and codec conversion, the increased load dedicated to processing session information can degrade the performance of these core operations. Accordingly, a need exists for improved methods, systems, and computer program products for managing, processing, and storing communication session information.